Summary

Three skill-level tightenings against failure modes Epic #190 exposed in today's dogfood run.

Failure 1: silent Epic exclusion

I filed Epic #190 with labels phase:11,enhancement,dogfood and forgot epic. The recommender's listOpenEpics (packages/dispatcher/src/github.ts) discriminates by the epic label. Without it, #190 dropped out of the queue entirely — not in Ready, Needs human input, Blocked, or even Excluded. It just vanished. ~90 minutes lost diagnosing "queue is stuck" before I noticed the label diff in the epics cache.

• creating-github-issues Phase 6 now states the epic label is required on parent Epics.
• creating-github-issues red flags gain a "forgot the epic label" entry naming the silent-disappearance failure.
• recommending-github-issues gains an explicit instruction to surface "issue qualifies as an Epic by all other rules but is missing epic label" in ## Excluded with an actionable reason. Silent exclusion is the actual bug.

Failure 2: needs-design as a safety blanket

The agent that shipped PR #198 (file-backed Epic store) filed follow-up #200 with needs-design despite all three gaps in the body carrying concrete implementation paths — file names, function names, data shapes, verbs. None were design forks; they were enhancements waiting on a worktree A/B. The needs-design label is the most expensive in middle's vocabulary (auto-dispatch skips it until a maintainer un-labels), and the agent used it as a "want human ack first" escape hatch — the corporate trap.

• creating-github-issues red flags + implementing-github-issues red flags both gain an explicit constraint: needs-design requires ≥2 specific candidate approaches AND a stated reason why building each as a worktree-A/B POC wouldn't decide. "Feels designy" / "want human ack first" / "more work than I want to handle in this PR" are explicitly rejected as rationales. Default is build to disambiguate.

I stripped needs-design from #200 today; the recommender will pick it up next tick.

Failure 3: complexity pause without an enumerated candidate list

The complexity-pause section (under "Running under middle") had the right structural rule — A/B/C up to complexity_ceiling, pause above it — but no enforcement against feelings of complexity. Agents have been pausing without writing down the candidates. Hardened to require the literal exercise of writing the fork list before any kind=complexity pause. The body now reads:

Mandatory before raising a complexity pause: write the candidate list. In blocked.json's context, list every fork by name with a one-sentence concrete approach (file paths + verbs, not vibes). If you can't articulate ≥ complexity_ceiling + 1 concrete forks this way, it isn't a complexity pause — you're rationalizing an easy choice as hard. […] Most "complexity pauses" don't survive contact with the list.

Three honest outcomes follow from the list: 1 fork = pick it; 2–3 forks = Architectural-forks worktree mechanic; ≥ complexity_ceiling + 1 distinct concrete approaches with no clear winner = real pause. The list is the gate.

Plus a matching red-flag entry: "This feels like a complexity pause → feelings aren't forks."

Verification

• bun run typecheck — clean
• bun run sync-skills — bootstrap-assets mirror re-synced
• bun test packages/cli/test/state-issue-body.test.ts packages/dispatcher/test/state-issue.test.ts — 19 pass

Summary by CodeRabbit

• Documentation
  • Parent issue guidance: parent issues must include the epic label to appear in recommendation queues.
  • Clarified needs-design: only for cases with multiple concrete, named implementation candidates where forks won’t resolve the choice.
  • Complexity pause: require an explicit, named candidate-fork list before pausing and specify outcomes (pick obvious winner, use forks for 2–3, pause only for many unresolved approaches).
  • Recommendation workflow: explicitly surface excluded epics missing the epic label with corrective instructions.